OpenEdge Getting Started:<br />Database Essentials Optimizing memory usage

Optimizing memory usage can be best described as taking advantage of the memory that you have. The general idea is to share memory where you can, use memory efficiently where possible, increase memory on the broker side first, and then increase client memory usage. In most cases, systems benefit from additional memory, but sometimes it is not possible to purchase additional memory. This section focuses on the trade-off between user and broker memory and how to use the available memory to your best advantage.

Buffer hits

The greater the percentage of time that the buffer is used, the lower the percentage of time the disks are used. Since memory is faster than disks, you will get better performance with a better buffer hit percentage. For example, a 90 percent buffer hit percentage equates to 10 disk reads for every 100 requests to the database manager. If you increase your buffer hit percentage to 95 percent, you are only doing 5 disk reads for the same number of requests, which is a 50 percent reduction in requests to the disk. A small change in buffer hit percentage can equate to a large reduction in disk I/O. This is especially noticeable at the high end; changing from 95 percent buffer hit percentage to 96 percent represents a 20 percent reduction in disk I/O.

Increasing memory

Memory is a limited resource. It is important to use it properly. In the case of a database application, it is important to increase broker parameters first because the payback extends across all users and the system as a whole. This fact is demonstrated with the previous database buffer hit percentage example. This example shows how a small change on the broker side can dramatically affect the entire system. The size of the change on the broker is usually smaller relative to any self-service client changes you might make.

For example, a 1000 buffer increase for the –B parameter on the broker of an 8KB-block-size database will cost you 8MB of RAM; an 80KB increase on the –mmax parameter for a 100-user system will cost the same 8MB of RAM. In the majority of cases, a buffer increase has a greater overall impact than the client change. This is a simple example, but it points out that you should always tune your broker parameters first. Once that is complete and you still have RAM to allocate, you can focus your attention on the self-service client parameters.

Decreasing memory

Determining where to cut back on memory is difficult. When decreasing memory you should use the opposite approach as was used for increasing memory; look at client parameters before broker parameters.

Direct IO

OpenEdge bypasses operating system buffers with the use of –directio, so the need for operating system buffers is limited. Operating system buffers will still be used for temporary file I/O for any client processes that reside on that machine. Most operating system manufacturers allow you to modify the number of buffers that can be allocated to the operating system. If you are using the -directio startup option, then you can reduce the amount of operating system buffers to approximately 10 percent in most cases. One major exception is systems with very limited memory (less than 256MB), where leaving the parameter at its default value is the best practice.

Private buffers (-Bp)

Private buffers allow a read-intensive user to isolate a portion of the buffer pool. Up to 25 percent of buffers can be allocated as private buffers. Private buffers work as follows:

The user requests a number of buffers to be allocated as private.

As the user reads records, if the corresponding buffers are not already in the buffer pool, the records are read into these buffers.

Instead of following the rules for buffer eviction, the user only evicts buffers that are in their private buffers. By default, the buffer that was least recently used is evicted. Private buffers are maintained on their own chain and are evicted by the user who brought them into memory.

If another user wants a buffer that is currently in another user’s private buffers, this buffer is “transferred” from the private buffers to the general buffer pool. The transfer is a process of removing the buffer from the user’s private buffer list and adding it to the general buffer list. The buffer itself is not moved.